home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000372_news@columbia.edu_Fri Dec 9 18:46:22 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB

  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10796
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 9 Dec 1994 13:46:28 -0500
  3. Received: by apakabar.cc.columbia.edu id AA01598
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 9 Dec 1994 13:46:26 -0500
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Problem with File Xfer (Binary vs Text) ??
  9. Date: 9 Dec 1994 18:46:22 GMT
  10. Organization: Columbia University
  11. Lines: 21
  12. Message-Id: <3ca8lu$1hs@apakabar.cc.columbia.edu>
  13. References: <D06y9C.8p9@nntpa.cb.att.com> <3bvb54$jmd@apakabar.cc.columbia.edu> <3c7r76$bn9@news.iastate.edu>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3c7r76$bn9@news.iastate.edu>,
  18. Gene Collins <collins@iastate.edu> wrote:
  19. >...I seem to be having a ... problem downloading zip files from a
  20. >bbs, specifically a Wildcat bbs.  I had set file type binary on
  21. >the pc before starting the download.  The transfer seemed to take
  22. >place ok, no error messages etc.  When I tried to unzip the
  23. >files, I was told that the files were damaged.  This is the same
  24. >procedure I've used several times with KERMIT 3.13.  I'm
  25. >currently using beta 14 of 3.14.  Any suggestions?  Thanks.
  26. >
  27. Only to make sure that the BBS Kermit software, whatever it is, has
  28. also been told to send the file in binary mode.  In general, it is
  29. the *file sender* that determines the transfer mode.  It sounds as
  30. if, in this case, the BBS was sending the ZIP file in text mode.  A
  31. good tipoff would be if the transferred file was bigger than the
  32. original file, and every carriage return in the transferred file
  33. was followed by a linefeed.
  34.  
  35. - Frank
  36.  
  37.